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The Total Network Data System (TNDS) is a coordinated family of 
operations systems that work together to mechanize telephone traffic data 
gathering and reporting. This paper describes the component parts of the 
TNDS, their functions, their interactions, and their inputs and outputs. The 
paper also presents the managerial view of TNDS: its product, its size, the 
number of people involved, how the overall project is organized and coordi- 
nated, and how the system evolves to meet the needs of a continually changing 
environment. 



I. INTRODUCTION 

The planning effort for traffic data collection and processing for 
what was to become the Total Network Data System (TNDS) began 
in the mid-1960s. This plan gradually evolved as the initial steps were 
taken to mechanize portions of the traffic data collection and data 
processing functions for the Bell Operating Companies and AT&T 
Long Lines. 

This paper is divided into two parts. The first part, Sections II and 
III, presents an architectural view of the Total Network Data System. 
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The second part of the paper (Section IV) is written from a managerial 
point of view. 

The first part begins (in Section II) with an overview of the current 
configuration of the TNDS, and the decisions that led to the current 
architecture; it concludes with brief descriptions of the functions of 
the individual subsystems and summaries of their interactions. (Sub- 
sequent papers in this volume describe the subsystems and their 
internal operations in detail.) Section III describes TNDS operations 
from a different point of view, i.e., by following the flow of a repre- 
sentative data item through the system and describing the database 
update process. 

The second part, which begins with Section IV, describes the product 
delivered to the end users, including software, documentation, and 
user support, as well as the organization of the development and 
maintenance effort, and the planning, requirements, development, 
test, and delivery cycle. Section IV also examines the need to enhance 
and update TNDS subsystems to meet changing needs, using the 
integration of the 5 ESS* switching system as an example. This article 
ends with a brief look at possible future directions. 

II. CURRENT CONFIGURATION 

This section introduces the architecture of the Total Network Data 
System and briefly describes the individual component systems and 
their interactions. Subsequent articles in this issue of the Journal 
describe the elements of TNDS in greater detail. 

TNDS is now widely deployed throughout the Bell System. All or a 
portion of TNDS is now in use in every Bell operating company. Of 
the almost 10,000 switching entities, TNDS collects and processes 
data for more than 7000. Since the switching entities not now con- 
nected are primarily the small electromechanical Community Dial 
Offices (CDOs), TNDS actually handles more than 90 percent of all 
Bell System traffic information. 

TNDS is a coordinated family of operations systems, which work 
together to mechanize the data gathering and reporting process. It 
consists of manual procedures and computer systems that enable 
operating company managers, network administrators, and network 
designers to analyze traffic data in a variety of ways. 

The development of TNDS has been under way since the mid-1960s. 
It was the Bell System's first set of integrated operations systems, and 
has required the planning, development, testing, modification, and 
introduction of a number of new features and generic programs. This 



* Trademark of Western Electric. 
2148 THE BELL SYSTEM TECHNICAL JOURNAL, SEPTEMBER 1983 



systems planning served as the forerunner of the main operations 
planning activities that have since characterized several plans, includ- 
ing the Total Network Operations Plan (TNOP). 

TNDS has now evolved into a system that encompasses 13 major 
component systems. They are: 

• EADAS — Engineering and Administrative Data Acquisition 
System 

• EADAS/NM — Engineering and Administrative Data Acquisition 
System/Network Management 

• TDAS — Traffic Data Administration System 

• LBS— Load Balance System 

• 5XB COER — No. 5 Crossbar Central Office Equipment Reports 

• SPCS COER— Stored Program Control Systems Central Office 
Equipment Reports 

• ICAN — Individual Circuit Analysis 

• SONDS— Small Office Network Data System 

• CU/EQ — Common Update/Equipment 

• TSS— Trunk Servicing System 

• TFS— Trunk Forecasting System 

• CU/TK— Common Update/Trunking 

• CSAR — Centralized Systems for Analysis and Reporting. 
Figure 1 shows the overall TNDS architecture. 

The elements of TNDS are operated in distributed locations. The 
switching systems, each serving thousands of customers, are generally 
based in a community's central office. The data collection systems 
typically employ dedicated minicomputers and gather traffic infor- 
mation from anywhere between 20 and 80 switching systems. Most of 
the remaining engineering and administrative reporting systems run 
on either general-purpose operating company computers, or at the 
AT&T computer center. 

Once collected and stored, a number of different systems of the 
TNDS may process the same items of traffic data to produce a variety 
of reports. 

Despite these distributed operations, the TNDS for any operating 
company can be thought of as a single, integrated entity designed to 
provide managers with comprehensive, timely, and accurate informa- 
tion about the network. 

2. 1 Architectural overview 

The Total Network System did not, like Athena from Zeus, spring 
full blown from the head of a grand planner. Instead it evolved, like 
most things, from a combination of several individual system devel- 
opments. R. L. Martin has observed 1 that the architecture of a system 
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Fig. 1— TNDS architecture. 

is the product of the history of the organization that builds it, the 
present and near-present technology, and the intended application. 
This observation is certainly true for TNDS. Its roots reach back into 
the 1960s. Its components originated in a number of organizations at 
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Bell Laboratories and the operating companies. The uses of its output 
within the operating companies are widespread and diverse. It is, 
therefore, not surprising that the TNDS architecture (shown in Fig. 
1) is not uniform or highly integrated. It is perhaps amazing that it 
fits together as well as it does. 

2. 1. 1 The primal components 

One of the earliest threads leading to TNDS began in 1966. A group 
of planning department representatives from eight associated compa- 
nies, along with Long Lines and AT&T, met in New York City and 
recommended a Bell System effort to centralize the development of a 
computerized trunk facilities system. Among the components recom- 
mended for development were a Traffic Trunk Estimating Subsystem 
and a Traffic Trunk Servicing System. Development of these two 
components began shortly thereafter in the Business Information 
Systems (BIS) area of Bell Laboratories as the Trunk Forecasting 
System (TFS) and the Trunk Servicing System (TSS). A third pro- 
gram, designed to acquire data from a variety of manual and mecha- 
nized sources and to distribute it to client programs, was also included 
in the planning. This program, called Identify and Edit, later became 
TDAS. 

Identify and Edit served as a data "warehouse." It labeled traffic 
measurements, stored them, and distributed batches of data to down- 
stream users as they were needed. It and the downstream systems it 
fed were designed to serve entire operating companies, and in some 
cases the entire Bell System. These downstream systems were placed 
on large mainframe computers to take maximum advantage of econ- 
omies of scale in processing, and to reduce the administrative problems 
of operating multiple systems. Another factor that led to these systems 
being company-wide in scope was the need for TFS to design company- 
wide trunk networks. This capability required a centralized database 
for trunk traffic measurements. It led to the centralization of the 
downstream systems with that database. The database, to which was 
added data for central office equipment, later became the CU/EQ and 
CU/TK components. 

During this early period, the place later taken by EADAS (see Fig. 
1) was occupied in planning by the Traffic Data Recording System 
(TDRS). TDRS was a special -purpose system that collected traffic 
data from electromechanical switching offices. Also during this period, 
AT&T planners expected to meet central office equipment data needs 
by standardizing programs developed by various telephone companies 
for individual switch types. The programs would receive data from 
Identify and Edit. Chief among these "Central Office Equipment" 
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programs was one developed by New Jersey Bell for No. 5 Crossbar 
offices (it was running in 1968). Later standardized by AT&T and still 
later revised by Bell Laboratories, this program became the present- 
day 5XB COER component of TNDS. 

The basic allocation of processing functions among these early 
systems has prevailed until now. TDRS was responsible for the real- 
time collection of traffic measurements for about 40 electromechanical 
switching offices. This number of offices was selected to balance the 
cost of switch-to-TDRS data links with the economics of scale avail- 
able with centralized processing functions. This basic configuration 
and size have continued with little change even though the role of 
TDRS has been taken over by EADAS. 

The early downstream systems (TSS, TFS, Identify and Edit, and 
5XB COER) were designed for batch processing on mainframe com- 
puters. This approach was the prevalent technology for large software 
systems in that era. It provided an economical way to meet user needs 
with minimal technical risks. Quick turnaround was not a requirement 
on the reports produced by these systems. These early systems have 
evolved and been enhanced over the last fifteen years. LBS and ICAN 
have been added. However, the fundamental architecture established 
in the late 1960s for this set of operating company, mainframe-based 
systems has changed little. Only now are on-line, real-time features 
being added. 

The arrangement of Central Office Equipment Reports (COER) 
systems within the TNDS architecture was driven by different factors 
than the other downstream systems. Each type of switching equipment 
has unique traffic data processing requirements. The switch architec- 
tures and service features strongly influence these requirements. This 
characteristic led to separate COER developments for each switch 
type. Only recently has the technology needed for a generic COER 
been pursued. 2 Several approaches were taken by the various organi- 
zations that developed the COER modules. As discussed above, 5XB 
COER is implemented on a mainframe system, and SPCS COER 
(which is a collection of COER modules) is implemented on a central- 
ized, time-shared system (as is SONDS). The selection of time sharing 
for these systems is discussed below. 

2.1.2 Evolution and integration 

In the early 1970s economical new minicomputer systems with 
greater flexibility and versatility replaced the specialized TDRS hard- 
ware being used for data collection. Some locally developed and ven- 
dor-supplied systems were installed for this purpose. The predominant 
system in use, however, is EADAS, which is a product designed by 
Bell Laboratories. Being real-time systems, these minicomputer sys- 
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terns could easily provide the short-term traffic reporting functions 
that were also required. 

Another major evolutionary step was the addition of network man- 
agement functions in 1975. Network management requires near-real- 
time data processing and requires an overview of a larger number of 
switching offices than can be served by one EADAS. However, the 
EADAS system provided a convenient and economic concentration 
point for the real-time, local office, traffic measurements needed for 
network management. Therefore, a decision was made to create a 
hierarchical architecture with up to six EADAS data collection mini- 
computers concentrated on an EADAS/NM minicomputer. For 4A 
Crossbar and 4 ESS toll switching offices, however, a direct switch- 
to-EADAS/NM connection was chosen because the number of these 
toll offices is relatively small and the data volumes interchanged with 
them are relatively high. It also provided a higher level of reliability 
for the communications with these critical switching entities. 

Three systems— SPCS COER, SONDS, and CSAR— were imple- 
mented on Bell System national-based time sharing systems. All three 
systems began as experiments conducted at Bell Laboratories to 
investigate improved traffic data management methods. For SPCS 
COER and CSAR, centralized time sharing was a means to deploy 
required on-line processing functions without the need for operating 
companies to buy additional hardware, or to support software in a 
number of geographically dispersed sites. These are attractive attri- 
butes for an experimental prototype. 

SPCS COER and CSAR were standardized on centralized time 
sharing because it was easier and more economical to evolve the 
prototype software than it would have been to rewrite it for another 
computer system and perhaps purchase new hardware. The decision 
to deploy SONDS on centralized time sharing was more difficult, 
however. 

The SONDS prototype was implemented on a minicomputer system 
at Bell Laboratories. It was determined that a single computer instal- 
lation could economically support all the Bell System's small step-by- 
step offices expected to utilize SONDS. These electromechanical 
switching offices were expected to be gradually replaced by electronic 
offices (served by EADAS) over a fifteen- to twenty-year period. The 
decision therefore was between: (1) standardizing the minicomputer 
prototype and supporting a centralized, dedicated minicomputer for 
15 to 20 years of declining switch population; or (2) rewriting all the 
prototype software for a general-purpose, time-sharing system. It was 
decided that users could get better support if the system was on a 
general-purpose computer. So SONDS joined CSAR and SPCS COER 
on the AT&T time-shared computer facility. 
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Integration of TNDS occurred as a series of steps. An early step 
was linking data collection to downstream processing. Minicomputer- 
based data collection systems like EADAS wrote traffic measurements 
on magnetic tapes that could be used as direct input to TDAS. The 
tape formats used for this link have been changed to improve process- 
ing efficiency, but the basic arrangement is still used. Integration of 
SPCS COER was another major step. Initially SPCS COER received 
data from punched paper tape via dial-up connections. In 1975, 
EADAS was upgraded to collect 1 ESS traffic data and pass it to 
TDAS via magnetic tapes. Data transmission from TDAS to SPCS 
COER was then used to complete the link. Other key integration steps 
were the automatic input to TFS of trunk group base load data from 
TSS, and linking the standard CSAR system by means of the down- 
stream CSAR merge program. As part of their initial development, 
EADAS/NM, ICAN, and LBS were all integrated. TNDS was officially 
recognized as an integrated system for planning purposes in 1974. 
This was accomplished by an internal Bell Laboratories memorandum 
which, in fact, declared it an integrated system and documented its 
architecture. 

The slow pace of evolution from the early architectural choices 
attests to their workability, but also is evidence of how difficult it is 
to change established architectures. As discussed at the end of this 
article, more changes are occurring. They are driven by the needs of 
users for new processing functions and technological advances that 
can be effectively incorporated into TNDS. Recently, developers have 
explored: (1) the use of on-line functions in mainframe systems for 
database management, report distribution and documentation deliv- 
ery; and (2) the migration of some functions on centralized time 
sharing to on-line mainframe systems. 

The remainder of this section describes, in more detail, the existing 
component systems and their current roles within the TNDS archi- 
tecture. 

2.2 Component system functions 

To understand the interrelationship of TNDS systems and how they 
collect and use traffic data, let's look at the four primary functions of 
TNDS in their general order of occurrence— data acquisition and 
management, central office equipment reporting, trunk network re- 
porting, and system performance measurement — and at the systems 
responsible for each function. 

2.2. 1 Data acquisition collection and management 

Managers need data on network performance and traffic loads 
carried by trunk groups and switching systems to assess the quality of 
service and to plan for network growth. 
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This network information begins as bits of data collected in switch- 
ing offices. For example, in electromechanical offices a specialized 
data collection device, called a Traffic Usage Recorder, scans the 
trunks and other components periodically (typically every 100 seconds) 
and counts how many are busy. Other traffic data such as peg count 
and overflow are also collected. In ESS offices, a similar process is 
used, but there is no need for specialized equipment, since traffic data 
are collected by the switching system's central processor. 

2.2.1.1 EADAS. Traffic data are transmitted to the first of the 13 
systems of TNDS— the Engineering and Administrative Data Acqui- 
sition System (EADAS). EADAS runs on dedicated minicomputers 
located at an operating company's Network Data Collection Centers. 
As its name suggests, it is the major data-collecting TNDS system. 
However, a few operating companies use locally developed or non-Bell 
vendor-supplied systems instead of or in addition to EADAS for this 
first step in the TNDS process. In addition, the large toll machines, 
4 ESS and No. 4 Crossbar [with its associated computer, the Peripheral 
Bus Computer (PBC)] collect their own data and do not connect to 
EADAS. 

Each EADAS serves up to 80 switching offices and, upon receiving 
traffic data, performs three basic functions. 

1. It processes some data in near-real time (shortly after they are 
received) to provide hourly and half-hourly reports and a short-term 
database for network administrators. 

2. It collects and summarizes data for processing by remaining 
"downstream" TNDS systems. 

3. It performs on-line surveillance and reporting functions. 
EADAS also links other TNDS systems by forwarding traffic data to 
them via a data link or magnetic tape. Three systems receive these 
data directly from EADAS. 

2.2.1.2 EADAS/NM. Two of three direct recipients of traffic data from 
EADAS are the Individual Circuit Analysis (ICAN) Program and the 
Engineering and Administrative Data Acquisition System/Network 
Management (EADAS/NM). They are the only systems that use data 
collected and processed by EADAS without first having it formatted 
by TDAS. ICAN is not a data acquisition system, but rather one of 
the central office engineering and administrative reporting systems, 
and is described in that section. TDAS is the third direct recipient. 

EADAS/NM is located at operating company Network Management 
Centers, and uses data received from EADAS or directly from some 
types of switching systems (e.g., 4A and 4E). It watches switching 
systems and trunk groups designated by network managers, and re- 
ports existing or anticipated congestion on a display board at the 
center. EADAS/NM also provides information to AT&T Long Lines' 
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Network Operations Center at Bedminster, N.J. This center is sup- 
ported by an operations system, the Network Operations Center 
System (NOCS), which performs functions similar to EADAS/NM, 
but on a national scale. 

2.2.1.3 TDAS. The Traffic Data Administration System (TDAS) 
formats traffic data for use, in turn, by a number of the other "down- 
stream" systems. 

But unlike EADAS and EADAS/NM— both of which employ dedi- 
cated minicomputers — TDAS runs in an operating company computer 
center supporting the Network Data Collection Centers. If TNDS 
were to be pictured as a series of distinct steps, then TDAS can be 
thought of as the second data acquisition step. Each week it accepts 
millions of pieces of data from EADAS (or the equivalent of locally 
developed or vendor-supplied systems) or directly from the large toll 
machines. In response to requests from downstream systems users, 
TDAS sorts, labels, stores, and, at the appropriate time, provides the 
data in the proper format to the engineering and administrative 
reporting systems. In effect, TDAS acts primarily as a warehouse and 
distribution facility for traffic data. 

TDAS treats its data acquisition job as a basic order/inventory 
problem. Orders, or Traffic Measurement Requests, for data are man- 
ually prepared and sent to TDAS by operating company personnel. 
These orders are stored in a master database. 

As traffic data are received by TDAS, they are matched against the 
orders held in Common Update. When the data necessary to fill an 
order have been received, a weekly data summary — either printed or 
on magnetic tape — is sent to the system that requests it to use in 
preparing an engineering or administrative report. 

Once TDAS has received, formatted, and sent data to the appropri- 
ate downstream reporting system, the data acquisition function is 
complete. At this point, traffic data have moved from the switching 
system to EADAS and then directly to TDAS and the requesting 
engineering and administrative reporting system. The next step is to 
look at how managers employ the TNDS systems to analyze the data 
that have been gathered. 

2.2.1.4 CU/EQ. In addition to the above systems, a common record 
base is used. TDAS and several of the downstream engineering and 
administrative systems need much of the same record-base reference 
information. Those data are maintained in a common system, called 
Common Update/Equipment (CU/EQ), rather than duplicated in each 
system. The information for each central office includes the configu- 
ration of switching equipment as well as specifications of traffic 
registers. This database is updated as changes occur in the physical 
arrangements of central offices. 
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2.2.2 Central office equipment reporting 

There are five downstream TNDS engineering and administrative 
systems that send reports about central office switching equipment to 
operating company personnel. These systems, which run on either 
operating company computers or at the AT&T computer center, are 
the: 

1. Load Balance System (LBS) 

2. No. 5 Crossbar Central Office Equipment Reports (5XB COER) 

3. Stored Program Control Systems Central Office Equipment Re- 
ports (SPCS COER) 

4. Individual Circuit Analysis (ICAN) Program 

5. Small Office Network Data System (SONDS). 

The first three receive traffic data from TDAS. ICAN receives data 
directly from EADAS, but also uses Common Update for some of its 
reference information. SONDS collects its own data directly from 
small step-by-step offices. 

2.2.2.1 LBS. The Load Balance System, LBS, which is run on the 
operating company computer, helps assure that the customer traffic 
load is uniformly distributed over each switching system. Customer 
lines are connected to the switching system "concentrators," which 
allow customers to share switching equipment. LBS analyzes traffic 
data coming to it from TDAS to establish the traffic load on each line 
group of each switching system. Then, personnel in the Network 
Administration Center use LBS reports to determine "lightly loaded" 
line groups to which new subscriber lines can be assigned. This 
minimizes congestion on a given concentrator. In addition, LBS cal- 
culates "load balance indices" for the entire operating company, indi- 
cating how effectively each central office has avoided congestion by 
efficiently distributing traffic. 

2.2.2.2 5XB COER, SPCS COER. Two other central office equipment 
reporting systems— 5XB COER for No. 5 Crossbar offices, and SPCS 
COER for 1, 2, 3, and 5 ESS offices— also use traffic data collected by 
EADAS and formatted by TDAS to support the Network Administra- 
tion Center. While 5XB COER runs on operating company computers 
and SPCS COER at the AT&T computer center, the two systems 
perform similar functions. Both analyze traffic data to indicate the 
overall load carried and the service provided by the switching systems, 
and to determine how much of the switching system's capacity is being 
used. This information helps planners decide when new equipment is 
needed and answers many other important administrative questions. 

2.2.2.3 ICAN. The two remaining central office equipment reporting 
systems, ICAN and SONDS, do not use TDAS to format their data. 
ICAN, which receives data directly from EADAS for certain electro- 
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mechanical offices equipped with an EADAS option called Individual 
Circuit Usage Recording (ICUR), detects switching system equipment 
faults by identifying abnormal load patterns on individual circuits. 
ICAN then produces a series of reports used at the Network Admin- 
istration Center to analyze individual circuit usage and verify circuit 
grouping. 

2.2.2.4 SONDS. SONDS — the fifth downstream central office equip- 
ment reporting system — is the only TNDS system that performs a full 
range of data manipulation functions. It economically provides a 
number of TNDS features for the smaller electromechanical step-by- 
step offices. 

To do that, SONDS— which runs at the AT&T computer center- 
collects traffic data directly from offices measured, processes them, 
and automatically distributes weekly, monthly, exception, and on- 
demand reports to managers at the Network Administration Center 
via dial-up terminals. 

2.2.3 Trunk network reporting 

Three TNDS systems — all run on operating company computers — 
support trunk servicing and forecasting at the Circuit Administration 
Center: 

1. Trunk Servicing System (TSS) 

2. Trunk Forecasting System (TFS) 

3. Common Update/Trunking (CU/TK). 

Together these three systems are sometimes referred to as Total 
Network Data System/Trunking (TNDS/TK). TSS helps trunk ad- 
ministrators develop short-term plans to relieve unacceptable blocking 
on final trunk groups. It processes traffic data supplied by TDAS, and 
computes the "offered load" for each trunk group. TSS calculates the 
number of trunks theoretically required to handle that traffic load at 
a designated grade of service — an objective expressed in terms of 
percent of blocking. TSS produces weekly reports showing which trunk 
groups are underutilized and which trunk groups are performing below 
the grade-of-service objective. 

The traffic load data calculated by TSS also help support the trunk 
forecasting function performed by TFS. Those data, in conjunction 
with information on network configuration and forecasting parameters 
stored in Common Update, are used for long-term construction plan- 
ning. The Trunk Forecasting System uses that information to forecast 
message trunk requirements for the next five years. These forecasts 
are a fundamental input to the planning process, which leads to the 
provisioning of additional facilities. 

CU/TK provides a common record base for TSS/TFS. It contains 
information describing the configuration of the trunk network. The 
traffic data are provided from TDAS. 
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2.2.4 CSAR system performance measurement 

Centralized System for Analysis and Reporting (CSAR) is the 
newest TNDS system. It was designed to monitor and measure how 
well data are being processed through TNDS from beginning to end. 
CSAR quantitatively measures the accuracy, timeliness, and complete- 
ness of the data flow for operating company personnel at the Network 
Data Collection Center, Network Administration Center, and the 
Circuit Administration Center. It also supplies sufficient information 
to locate trouble so corrective action can be taken. It does not presently 
analyze data from EADAS/NM, SONDS, or TFS. 

CSAR is an on-line, interactive system that puts TNDS performance 
information at the user's fingertips. At the conclusion of each run of 
a system in TNDS, data required by CSAR are placed in a special file. 
Then, at an appropriate time, they are transferred to the AT&T 
computer that contains the CSAR program. CSAR then performs the 
proper association and analysis of data. 

Operating company managers can access the report information 
from terminals at their own work locations. The reports can be 
arranged in a number of formats, and can provide details on overall 
TNDS performance or individual system effectiveness. Reports can 
be broken down by traffic unit (trunk group or switching system), 
district, division, or area to help identify and resolve problems at 
various operating company organizational levels. 

III. HOW IT WORKS 

This section will describe the end-to-end data flow of TNDS using 
two examples. One example will explain the steps necessary to pass 
Touch-Tone* dialing originating register data from a No. 5XB office 
to the 5XB COER system, and the other will focus on the delivery of 
trunking data from a 1 ESS office to TSS. In both cases considerable 
preparation is necessary in the switching office and in the databases 
of the affected TNDS subsystems before data flow can begin. This 
preparatory work will be described first. 

3. 1 Addition of Touch-Tone originating registers in a No. 5XB 

Generally, the marketing department would decide that the level of 
customer demand was sufficient to justify the cost of purchasing and 
establishing a Touch-Tone originating register (OR) group in a No. 
5XB office. Following this decision, the Traffic Engineer would engi- 
neer the addition using forecasts of usage and would write a traffic 
order for the new equipment. A copy of the order would be received 



* Registered service mark of AT&T. 
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by Network Administration personnel whose job it is to assign the 
Touch-Tone equipment to measurement devices. After the assign- 
ments are made, central office personnel will connect the leads of the 
Electronic Traffic Data Collection (ETDC) unit to the Touch-Tone 
equipment. 

Traffic counts are maintained on a data collection device (DCD). 
Before data collection was computerized, traffic measurements were 
accumulated in mechanical registers. The modern equivalent to these 
registers are the DCDs, which are the software storage locations of 
the accumulated counts. For our example these storage locations are 
in the EADAS memory, although many of the subsystems of TNDS 
use DCD locations to refer to traffic measurements. The DCD is the 
common thread that links the traffic measurements from the switching 
office through EADAS and on to other systems. 

A typical No. 5XB may require 1500 DCDs. The important mea- 
surements collected in DCDs on the Touch-Tone group are identified 
and defined in Table I below. As illustrated in Fig. 2, the next step in 
the sequence of preparing individual systems is loading the EADAS 
database (by defining the new DCDs) to accept the new data and to 
print exception and hourly reports. 

The mapping between the ETDC at the switching office and the 
EADAS is accomplished via the DCDs. Likewise, the DCD is the link 
between EADAS and TDAS. The user prepares TDAS to receive this 
new data from EADAS by modifying the CU/EQ database using input 
transactions. Each TNDS equipment (TNDS/EQ) system except 5XB 
COER shares some portion of the CU/EQ database; hence, each 
system is assigned a series of numerically coded transaction commands 
to allow the database to be changed. As examples, a 750 transaction 
is used to associate a DCD with a particular measurement type, such 
as Touch-Tone OR peg count, and the days of the week and hours of 
the day that measurements need to be processed by TDAS are specified 
on the Traffic Measurement Request (790) transaction. 

The CU/EQ database can be modified to enable 5XB COER to 
begin processing Touch-Tone OR data and printing reports. Once this 
is accomplished, all pieces are in place to permit traffic data to flow 

Table I — DCD measurements on the Touch-Tone group 

Measurement Type Definition of Measurement 



Usage An estimate of the total amount of time the Touch- 

Tone ORs were busy for any reason. 

Peg Count The total number of attempts made to access the 

Touch-Tone ORs. 

All Touch-Tone Registers Busy The number of attempts to seize Touch-Tone ORs 

when the entire group was busy. 

Maintenance Usage The total amount of time the Touch-Tone ORs were 

busy for maintenance reasons. 
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Fig. 2— Database synchronization for Touch-Tone originating register data. 

from the physical equipment to the Network Administrator and 
Traffic Engineer. However, two potential users of this data have not 
yet been included. Those users receive data by an indirect path rather 
than the main-line path described thus far. Personnel at the network 
management center receive traffic measurements on critical switching 
office components in near-real time. To prime EADAS/NM to receive 
certain of the Touch-Tone OR measurements directly from EADAS, 
the EADAS/NM database is modified by identifying the new mea- 
surements (DCDs) that will be available at the EADAS. 

Selected data from each of the 27 EADAS/NM systems are sent to 
the NOCS computer every five minutes. These data describe the status 
of toll switching offices and trunk groups, but not the status of the 
local network. Thus, the new No. 5XB data would not be forwarded 
to NOCS. Data from toll switching offices are sent to NOCS by 
identifying it in the EADAS/NM database as being of NOCS interest. 
An EADAS/NM program automatically notifies NOCS that new data 
will be sent to it by forwarding a database map to NOCS. This program 
synchronizes the NOCS database to the EADAS/NM database. 

The final system to receive these new measurements is CSAR. 
However, since CSAR measures overall performance rather than spe- 
cific items, no database changes are required. 
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Now that all record base components are ready, the flow of new 
data can be monitored through each system. Figure 3 graphically 
illustrates this flow. 

Data collection starts with the customers; their Touch-Tone calls 
cause attempts (peg counts), usage, and, during high load periods, an 
occasional all-busy condition on the Touch-Tone ORs. (Maintenance 
usage is generated by the central office work force when they remove 
an OR from service to maintain or repair it.) The ETDC is signaled 
each time an attempt is made to seize a Touch-Tone OR. The ETDC, 
in turn, codes a message, which is sent to EADAS when a seizure is 
attempted. This coded message is simply the DCD for that measure- 
ment. The ETDC, located at the switching office, is connected to the 
EADAS, which generally is physically remote from the ETDC. 

For each switching office served by an ETDC, a block of DCDs in 
the memory of the EADAS records all the traffic measurements being 
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Fig. 3— Flow of Touch-Tone originating register data through TNDS. 
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collected. These banks of DCDs are forwarded to EADAS/NM every 
five minutes when a command is sent from EADAS/NM over a data 
link. EADAS transmits data from all of the offices requested by 
EADAS/NM, including the No. 5XB with the new Touch-Tone ORs. 
After receiving data, EADAS/NM performs calculations on that data 
and displays the results nearly instantaneously to the network man- 
ager. If data from the No. 5XB were of national interest, every five 
minutes they would be forwarded to the NOCS where calculations 
would be performed and data displayed to national network managers. 

Network management requires 5-minute data, whereas traffic en- 
gineering requires hourly data. Starting either on the hour or at half 
past the hour, EADAS writes the current DCD counts to magnetic 
tape and resets these registers to zero. 

One of the major benefits of EADAS is its exception-reporting 
capability. The network administrator can define an exception con- 
dition such as some number of occurrences of all ORs busy in a 30- 
minute period. If this frequency occurs or is exceeded, a report would 
be printed at the EADAS teletypewriter (TTY) and the network 
administrator would take the appropriate action. 

Periodically, the magnetic tape will be forwarded to a data processing 
center. These tapes will be run through TDAS, which will perform 
some validations and "warehouse" the data. TDAS will then create 
new tapes, one for each TNDS downstream system. One tape produced 
by TDAS would be processed by 5XB COER, which would then 
perform validation tests and calculations on the data and generate 
output reports to be used by the network administrator and traffic 
engineer. These reports would be used to determine if the new equip- 
ment was being utilized effectively while providing an acceptable grade 
of service to the customer. In most companies, the 5XB COER program 
is run weekly with a TDAS tape containing each day of the week used 
as input. The key report generated by 5XB COER is the Machine 
Load Service Summary (MLSS) report, which displays the ten high- 
day loads and the average busy season load on most switching office 
components, including the new Touch-Tone ORs. The MLSS report 
is also used by traffic engineers to determine equipment quantities for 
the next busy season. 

At key checkpoints, traffic measurements are monitored by CSAR 
to ensure that they are received, processed, and are reasonably accu- 
rate. If, for example, the DCD associated with Touch-Tone OR usage 
were improperly wired, the occupancy of this equipment could erro- 
neously appear to be greater than 100 percent. CSAR would be notified 
of these invalid measurements and would include this problem in the 
calculation of the index. Besides producing the index, CSAR identifies 
problem areas, thus facilitating their correction. 

SYSTEM PLAN 2163 



3.2 Addition of a new trunk group to TSS 

The previous example gave an overview of how TNDS collects and 
processes equipment data from an electromechanical office. In con- 
trast, the next example describes how trunking data is collected from 
a 1 ESS office and processed by TSS. As before, we will start with a 
description of the record base process needed to support this data flow. 
In this case, we will describe the effort needed to add a new trunk 
group between two 1 ESS offices. For this example, measurements 
will be collected at only one end of the group, hence, data will be 
needed from only one 1 ESS office. 

Generally, the recommendation to add a new trunk group would 
come from TFS as part of the forecasting process. At the time the 
group need is forecasted, it is added to the CU/TK database. The 
trunk servicer would write an order to have this new group installed 
and specify the schedule for data collection. The order would pass 
through organizations responsible for assigning and installing equip- 
ment to make the trunk group operational. One step of this operation 
would be assigning the group a trunk group serial number (TGSN). 
The TGSN is similar to the Common Language Location Identifier 
(CLLI); it is the unique identification for a trunk group in the elec- 
tronic switching system office. These offices do not require ETDCs; 
they store counts in their memory and later forward them to the data 
collection computer. 

Figure 4 illustrates the steps necessary to prepare each subsystem 
to collect and process data from this new trunk group. These steps are 
similar to those in Fig. 2; the major difference occurs at the switching 
offices. Traffic measurements are specified in software of the 1 ESS 
switching equipment. This includes the EADAS/NM requirements for 
five-minute data on the new trunk group and requirements for half- 
hourly data on the TSS and the other downstream systems. The new 
trunk group is added to the EADAS and EADAS/NM databases with 
the TGSN being used to identify the group and the DCDs used to 
identify individual measurements. If the trunk group is of national 
interest, it will be marked in the EADAS/NM database to be sent to 
NOCS. 

Record base information for this new group is entered for TDAS 
and TSS via CU/EQ and CU/TK. As before, transactions are used to 
define the new measurements, and the time period during which these 
measurements will be processed, and to specify the new trunk group. 
Once the record bases have been modified, all subsystems are prepared 
to process this new group. The next section will trace the data flow 
from the office to the end users. 

Figure 5 shows each step of this data flow. The major difference 
between this example and the previous one occurs at the front end— 
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Fig. 4— Database synchronization for trunk group data. 

between the switching office and data collection computer. When an 
attempt is made to seize the new group, a peg count is stored in a 
memory location at the 1 ESS office. The system passes these data 
forward upon request from the EADAS. Every five minutes EADAS/ 
NM requests data from the EADAS. In the previous example, data 
were already in the data collection computer. However, for this ex- 
ample the EADAS must request data from the ESS offices that it 
serves. Raw counts are forwarded to the EADAS, which then subtracts 
the previous readings and forwards them to EADAS/NM. As before, 
EADAS/NM processes these data and displays them to the network 
manager. If this lESS is a key part of the toll network, data from the 
new group could be forwarded to NOCS for display. 

To satisfy the needs of engineering, much more data are passed 
from the ESS office to the EADAS on the hour and half hour. These 



SYSTEM PLAN 2165 



EADAS/NM 



ATTEMPTS 
I 

| NO.] ESS 




EVERY FIVE MINUTES 
UPDATED COUNTS ARE 
RECEIVE FROM EADAS. 
THESE NEW DATA ARE 
PROCESSED AND DISPLAYED. 



TSS 



TTY 



AN ATTEMPT TO SEIZE 

A TRUNK IN THE NEW 

GROUP CAUSES THE ESS 

SOFTWARE TO INCREMENT 

A COUNTER IN MEMORY. 

THE CONTENTS OF THESE 

COUNTERS ARE PASSED TO 

THE EADAS ON COMMAND. 



EVERY FIVE MINUTES 

DATA ARE REQUESTED 

FROM CSS OFFICE 

FOR NETWORK 
MANAGEMENT AND 
AND FOWARDED TO 

EADAS/NM. 

EVERY HALF HOUR 

DATA ARE REQUESTED 

FROM ESS OFFICE 

FOR DOWNSTREAM 

AND WRITTEN TO 

TAPE. REPORTS 

ARE PRINTED ON TTY. 



Q 



CU/EQ 



Q 



TDAS TAPE IS 
PROCESSED AND 
REPORTS THAT 

INCLUDE NEW GROUP 
ARE GENERATED 



♦TRADEMARK OF WESTERN ELECTRIC. 



WEEKLY, TOAS PROCESSES 

NEW TAPES FROM EADAS 

ACCORDING TO REVISED 

CU/EQ DATABASE AND 

CREATES INPUT FOR TSS. 



CU/EQ - COMMON UPDATE/EQUIPMENT 
DCD - DATA COLLECTION DEVICE 
EADAS/NM - ENGINEERING AND ADMINISTRATIVE DATA 

ACQUISITION SYSTEM/NETWORK MANAGEMENT 
TDAS - TRAFFIC DATA ADMINISTRATION SYSTEM 
TSS - TRUNK SERVICING SYSTEM 

Fig. 5 — Flow of trunk group data through TNDS. 

data are written to tape and handled identically to the previous 
example. TDAS generates a separate tape to be processed by TSS and, 
as frequently as weekly, the TSS subsystem is run to process the data 
and generate reports. In the case of the new group, the servicer would 
closely examine its performance to determine if the number of circuits 
in the group was a good match to the load being offered to the group. 
If a mismatch occurred, an adjustment in the circuit quantity would 
be made after a pattern of performance for that group was established 
by running the TSS program several times with new traffic data. 

As was the case for equipment data, CSAR monitors the flow of 
trunking data, calculates an index on this portion of TNDS, and 
produces reports that highlight problem areas. 

IV. MANAGING SYSTEMS ENGINEERING AND CONTINUING 
DEVELOPMENT 

From the descriptions above, it is clear that from the user viewpoint, 
TNDS is large and complex. It is even more complex from a software 
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engineering viewpoint. This section describes how the software engi- 
neering for this large and complex system is managed. 

4. 1 End products and services 
4.1.1 What is provided 

The TNDS organization provides various end products and services 
to the users. Although the specific details vary among the systems in 
TNDS, the end products and services can be categorized as follows: 

1. Software 

2. Documentation 

a. End user 

b. System Operation 

3. Training 

4. User Support. 

The software is in the form of load modules for the specific machine 
on which the system is run. The load modules for systems run in each 
operating company are sent by tape or high-speed data transmission 
and then loaded. System operations personnel install the load modules 
using the installation guide provided. For centralized systems (e.g., 
SPCS COER, CSAR, and SONDS), development personnel install the 
new load modules. 

The documentation provided falls into two categories: end user and 
system operation. End user documentation provides network person- 
nel with information on how to interface with the system. This 
documentation is usually in paper form, but in the case of SPCS 
COER and CSAR, it is on-line at the user terminal with the option of 
printing. Each operating company also receives documentation for 
system operation from an Electronic Data Processing (EDP) viewpoint 
for the systems run at that site. This documentation includes infor- 
mation on backup and recovery procedures, resource requirements, 

etc. 

The TNDS/EQ-TNDS/TK training philosophy is to train the train- 
ers— TNDS coordinators and trainers in each operating company— 
by giving them the information they need to hold similar training 
courses in their companies. Both user and EDP training is provided. 
In addition, special release-oriented training usually supplements the 
basic system training. 

User support for each operating company is usually in the form of 
an assist line (or "hot line") number, which the user can call when 
questions or problems arise. 

4. 1.2 Size of the product 

Table II shows the relative size of each end product and service for 
each system in the TNDS. The lines of source code are in various 
high-level languages (PL/I, COBOL, FORTRAN, and C). 
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Table II — TNDS software and documentation 





Lines of Code 
(Thousands) 


Pages of Documentation 




User 


EDP 


EADAS/NM 


900,000 


700 


800 


EADAS 


200,000 


3500 


500 


TDAS 


75,000 


1725 


1334 


CU (CU/EQ and CU/TK) 


119,000 


586 


2527 


ICAN 


43,000 


1445 


318 


LBS 


42,000 


1764 


560 


5XB COER 


128,000 


2215 


340 


SPCS COER 


450,000 


1000* 


20 


CSAR 


125,000 


200* 


48 


TSS 


166,000 


1805 


641 


TFS 


80,000 


2086 


2788 


SONDS 


178,000 


380* 


30t 


Total (Rounded) 


2,328,000 


17,000 


10,000 



* On-line lessons, 
t Binders. 



4.1.3 TNDS deployment 

Another important factor that affects managing the TNDS is its 
extensive deployment. Table III illustrates the extent of deployment 
of each component system in TNDS. Looked at another way, some or 
all of these systems are deployed in all of the operating companies and 
several are deployed in Bell of Canada. 

4.2 Managing change 

Although TNDS is a mature system that has been widely deployed 
and operating in Bell operating companies for some time, the systems 
are still undergoing extensive development to keep up with the chang- 
ing operating environment and to furnish improved capabilities. A 
goal of this continuing development process is to furnish users period- 
ically (usually yearly) with new versions of the systems that incorpo- 
rate needed changes in a timely manner. To achieve this goal, several 
factors must be considered. 

1. The total number of possible improvements is generally much 
greater than the resources available for a particular release. 

2. The calendar time required to develop a given release is much 
longer than one year. 

3. A change frequently has impact in more than one of the systems 
of the TNDS. 

These factors result in a need for careful planning to choose among 
the capabilities to be incorporated into a release, to begin planning 
well before the targeted release date, and to carefully coordinate 
planned changes among the systems. A formal approach called the 
TNDS Release Cycle is used to satisfy these needs. 
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4.2. 1 The nature of change 

TNDS software and hardware are modified and enhanced for many 
reasons. First of all, designers must run to stay even with the rapidly 
evolving telephone network equipment, services, and operating pro- 
cedures. Next additional features are needed by TNDS users and 
operators. And to prevent the system from becoming technically 
obsolete, it is necessary to make changes that improve the efficiency, 
maintainability, and expandability of software and hardware compo- 
nents. Examples of changes to the telephone network that have been 
accommodated in TNDS include the addition of new switching system 
equipment such as 5 ESS (the management of this change is discussed 
further below) and the use of new extreme value load engineering 
procedures. Recent additions include mechanization of ESS busy-hour 
determination studies, and new reports for No. 5 Crossbar administra- 
tors. There have been technical improvements to TNDS. Some ex- 
amples are run time and disk utilization improvements, the complete 
rewrite of the No. 5XB COER module to improve its maintainability, 
and the conversion of EADAS to the UNIX* operating system, which 
simplified the addition of new features. 

New releases of software modules usually contain a mixture of 
enhancement types. A recent TNDS/EQ release is typical. It contains 
features that support 5 ESS data collection, a new 2B ESS traffic 
data collection interface, and improvements to allow automatic trans- 
fer of ESS capacity statistics from EADAS to SPCS COER. This 
release also eliminates software that supported now obsolete data 
collection equipment. Several software functions were simplified, in- 
cluding the interface with one non-TNDS system, the distribution of 
traffic register definition listings, and company parameter tables. Also, 
thirteen separate changes to improve operational efficiency were made. 

4.2.2 The release cycle 

The TNDS release cycle covers the overall planning, development, 
and project control processes to be employed to produce the major 
releases of systems in the TNDS. For release purposes, these systems 
are grouped into seven sets as outlined in Fig. 6. 

Each of these groupings has a separate release cycle, all of which 
are coupled to varying degrees. In particular, the cycles of EADAS, 
TNDS/EQ, SPCS COER, and CSAR are tightly coupled because of 
feature interactions. These systems all support the Network Admin- 
istration function. On the other hand, release of EADAS/NM and 
TNDS/TK (supporting network management and trunk administra- 
tion, respectively) are less dependent on the other systems and on 
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Fig. 6— TNDS release coupling. 

each other. Finally, SONDS is a complete mini-TNDS for a specific 
class of offices (SXS CDOs), and consequently is more independent 
of intersystem interactions than other systems in the TNDS. 

The following discussion applies in general to all the TNDS systems, 
but in detailed examples, the release cycle for TNDS/EQ will be used. 

4.2.3 Project phases 

The project phases in the release cycle define a continuing devel- 
opment process. The phases are divided into major categories and 
subcategories as shown in Fig. 7 and as listed below: 

1. Planning 

2. Implementation 

a. Requirements 

b. Design, code, and test 

c. Soak 
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Fig. 7— TNDS release cycle. 

3. Operation 

a. Transmittal of planning information 

b. Release training 

c. Installation. 

4.2.3.1 Planning. For the continuing development process, inputs 
come from many sources — operating companies, AT&T, and Bell 
Laboratories. Operating companies submit change requests to the 
AT&T project managers. These managers as well as Bell Laboratories 
designers and systems engineers also initiate proposals. These inputs 
are diverse. They range from requests to fix bugs or design errors to 
major development programs. The AT&T project managers and Bell 
Laboratories systems engineers, often with the advice of telephone 
company user representatives, perform an initial screening and clas- 
sification of the inputs. In this step the inputs are classified into 
maintenance items, desirable improvements, and rejected suggestions. 
Maintenance items are transferred to the maintenance organization 
for the component system involved. Rejects are returned to the origi- 
nator with an explanation of the reason for rejection. Desirable im- 
provements are included in one or more "feature" packages. 

Feature packages are specific development items that can be as- 
signed individual priorities. They usually involve only one component 
system, but may be dependent on feature packages for other compo- 
nent systems for implementation. The assignment of individual items 
to feature packages has several advantages. Related items can be 
developed more efficiently as a group rather than separately. Items 
with similar objectives can be combined or modified to create improve- 
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ments with more global and more universally useful objectives. And 
since improvements often are suggested in terms of implementation, 
the same objectives sometimes can be accomplished as part of an 
already scheduled or more easily accomplished feature. 

Certain time-critical features may be worked into ongoing develop- 
ment of forthcoming releases. These "expedited enhancements" gen- 
erally must be small and very important because they displace other 
planned work. The level of management approval required for expe- 
dited enhancements depends upon the nature of the work being 
displaced. The remaining features are subjected to a much longer 
obstacle course. They must compete for the limited resources available 
for TNDS ongoing development. 

Feature packages are carefully evaluated by Bell Laboratories sys- 
tems engineering and development, by AT&T project managers, and 
by telephone company user representatives to establish their priority. 
Metrics for comparative evaluation include economic benefits, esti- 
mated development cost, and estimated length of time to develop. 
Other intangible factors that are considered in setting priorities are 
potential quality-of-service improvements, needs to adhere to AT&T 
corporate policies or operating practices, and the need to respond to 
FCC or state regulatory commission requests for data. 

Feature lists in priority order are maintained on a permanent basis 
and are updated periodically. Separate lists are maintained for TNDS/ 
TK, TNDS/EQ, SPCS COER, EADAS, and EADAS/NM. Any de- 
pendencies on other TNDS or non-TNDS features are noted. These 
priority lists are used as input for planning specific new TNDS 
software releases. Priorities may be time-dependent, that is, a certain 
feature, such as support of a new switching entity may not be needed 
until some future date. After that date, the importance of the support 
increases with the expected deployment of the switch. 

Release planning is the responsibility of Bell Laboratories systems 
engineers working with each of the TNDS component systems. They 
consider the engineering resources available, the priority of proposed 
features, and length of time for development to formulate the content 
of proposed releases. These proposals are reviewed by AT&T project 
managers, telephone company user representatives and, when appro- 
priate, Western Electric product line managers. Changes, if any, are 
made, and the priority of each of the features in the release package 
is established. This release priority is used to eliminate work when the 
inevitable resource constraints and expedited enhancements arrive. 
While approvals for the proposed release packages are being obtained, 
work will usually start on requirements for the features in the proposed 
package. Sign work, however, starts after final approval. 

4.2.3.2 Implementation. The first step toward implementing a 
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release is to complete detailed requirements for each feature. These 
are reviewed and approved, and they are one of the key project control 
documents. 

The design step then translates the requirements into the code 
changes to be made. Design is divided into two parts: (1) system 
design, which identifies the modules, files, and interfaces (e.g., trans- 
action and report layouts, intersystem interface definitions) to be 
changed; and (2) detail design, which identifies the coding changes to 
be made in each module. After system design is complete, the devel- 
opment organizations formally commit themselves to the contents and 
schedule for the release. After detail design, the changes are then 
coded and tested. 

Finally, a soak test of the product is performed in one operating 
company site. The soak process determines if the end product performs 
in accordance with the requirements, is capable of satisfying user 
needs, and is worthy of systemwide release. The soak site is selected 
based on environmental requirements needed to exercise the features 
in the release. Soak periods vary by system but usually last from three 
to six months. After a soak is successfully completed, the release is 
made available for installation in other sites. 

4.2.3.3 Operation. The first step an operating company takes in 
installing a release is receipt of planning information in the form of a 
Product Release Description, which is usually made available approx- 
imately four months prior to the general availability date. 

Also prior to general availability, release training information is 
made available and training classes are held. Documentation for the 
release is also made available in this time frame. 

When the release is available it is installed in other sites. Each site 
is expected to install the release within a reasonable period (usually 
six months), at which time continued support of the previous release 
is terminated. 

General availability dates are usually chosen to allow installation 
during a time period that is not in the traffic busy season when data 
collection is critical. 

4.2.4 Release cycle timing 

The phases of the release process are integrated into an overall 
release cycle as shown in Fig. 7. This figure depicts the major activities 
within the cycle and the time intervals typically required to conduct 
each of these activities. Roughly three years are required to complete 
all of the phases for a particular release. With releases planned for 
annual delivery, this implies that at any point in time, development 
activities will be in progress on three different releases. The overlap- 
ping of releases is shown in Fig. 8. 
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Fig. 8— Parallelism between releases. 



4.2.5 Interproject coordination 

For the subset of TNDS features that involve development in 
multiple component systems or in non-TNDS systems, an interproject 
coordination activity must be overlaid on the internal TNDS control 
process. Features in this category are few hut often large, important 
development efforts. An example of such a development is supporting 
a new switching system like the 5 ESS system. Coordination involves 
establishing overall requirements for TNDS support, identifying spe- 
cific "features" to be developed in each component system, and nego- 
tiating a coordinated development program for these releases. The 
development program may involve work in both TNDS and non- 
TNDS systems. Often, project committees are formed to coordinate 
requirements, design, testing, and soak of both the hardware and 
software components. Always there is an exchange of documentation 
at each step in the process. Interfaces are defined and documented as 
early as possible. 

To make the continuing development process work, it is essential 
that continual communication among all the people involved be main- 
tained. A permanent AT&T, Bell Laboratories, Western Electric 
management committee has the responsibility to see that communi- 
cations are maintained and that problems in the continuing develop- 
ment process are resolved. The process has enabled TNDS to evolve 
with changes in the telephone business, become more efficient, grow 
in services to its users, and introduce new technologies, where 
appropriate. 
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4.3 The organization structure 

TNDS software engineering takes a large number of people working 
effectively together with well-defined individual responsibilities. Be- 
cause of the size of TNDS, the organization is structured functionally 
with each organizational group having responsibility for one or more 
of the project phases defined above and for one or more of the systems 
in the TNDS. 

4.3. 1 Functional structure 

Three types of organizations divide up the work in the release 
cycle — Systems Engineering, Development, and Western Electric 
Product Engineering Control Center (PECC). 

4.3.1.1 Systems engineering. Systems Engineering organizations 
have responsibility for the planning and requirements phases, and 
they participate in the soak evaluation. 

4.3.1.2 Development. The development organizations are responsi- 
ble for design, coding, and test, and they also participate in the soak 
evaluation. 

4.3. 1.3 Role of Western Electric. Western Electric PECC organiza- 
tions are responsible for (1) developing documentation, (2) devel- 
oping training and giving classes, (3) coordinating and performing 
soak evaluation, (4) maintaining installation support, and (5) provid- 
ing customer consultation. 

4.3.2 Project structures 

Figure 9 shows the structure of the TNDS organization in terms of 
responsibility for systems engineering and development. Each circle 
represents a separate department in Bell Laboratories. Those organi- 
zations on the left are responsible for systems engineering, and those 
on the right for development. The systems for which the organization 
is responsible are indicated in the circle. Also indicated above the 
circle is the physical location of the organization (Holmdel, Columbus, 
Piscataway, West Long Branch, and AT&T Data Systems in Pisca- 
taway). Note that many Western Electric organizations involved in 
TNDS are not shown on the chart. 

4.4 A continuing development example — the marriage of TNDS and 5 ESS 

The 5 ESS switching system is a new, Bell Laboratories-designed 
system that recently went into service with full TNDS support in 
place. Planning and implementation of this support has occurred in 
parallel with the development of the 5 ESS switching equipment. To 
illustrate the TNDS continuing development process, we will use the 
history of TNDS support for 5 ESS switching equipment. 
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Fig. 9— TNDS organizational interactions. 

Almost four years before the scheduled cutover of the first 5 ESS 
switching equipment, its development organization began to consider 
alternatives for handling the traffic data, and the needs for specific 
types of measurements. A joint AT&T, Bell Laboratories task group 
was formed to consider 5 ESS traffic data-handling needs. Experts on 
5 ESS development, traffic engineering methods, TNDS, and tele- 
phone company data needs were assigned to the group. This task force 
recommended an overall strategy for handling 5 ESS traffic data and 
identified a number of specific work efforts needed to implement the 
strategy. The recommendations of this group established the objectives 
for the several work activities that followed. Key recommendations of 
this group included: 

1. Allocating all traffic data-handling functions except basic mea- 
surement and measurement distribution to TNDS. 
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2. Using extreme value engineering techniques for timing and sizing 
of 5 ESS additions. 

3. Collecting traffic data for trunk and switching equipment engi- 
neering, division of revenue, service provisioning, switching adminis- 
tration, and network management through EADAS. 

4. Selecting peak values in EADAS for extreme value engineering. 
Work activities included: 

1. Developing extreme value engineering methods and measurement 
requirements for 5 ESS switching equipment. 

2. Formulating a TNDS plan to support 5 ESS switching equip- 
ment. 

3. Formulating requirements for 5 ESS features needed to deliver 
required measurements to EADAS. 

The task group's recommendations were accepted by AT&T and 
Bell Laboratories managers, and work started on the above tasks. The 
work proceeded in parallel. 

The first step in the TNDS planning effort was identifying TNDS 
outputs required for 5 ESS switching equipment and the TNDS 
developments needed to provide these outputs. Descriptions were 
developed, by individual component system, of the feature packages 
needed to support 5 ESS switching equipment. Table IV identifies the 
changes needed to TNDS. Following identification of the necessary 
features a tentative schedule was established for requirements for- 
mulation and component system design. This schedule was coordi- 
nated with the estimated schedules for the engineering methods work, 

Table IV — TNDS developments for initial 5 ESS service 

System Development Required 

EADAS X.25 interface with 5 ESS switching equipment 

Peak measurement selection 

Complete Network Operation Report Generation (NORGEN) re- 
port package 

EADAS/NM No development for first service. (Full EADAS/NM support will 

be provided in stages with development of advanced versions of 
5 ESS switching equipment.) 

TDAS 5 ESS measurement identification 

CU/EQ Peak measurement handling 

5 ESS statistics for CSAR 

SPCS COER Complete package of engineering and administrative reports for 

processing extreme value statistics 
5 ESS statistics for CSAR 

LBS No development needed for first service. (Development to support 

a new 5 ESS load balance index will be required later.) 

TSS, TFS, CSAR No development required as current software is sufficiently general 
to handle 5 ESS switching equipment. 

5XB COER These systems support electromechanical switching entities. No 

ICAN changes for 5 ESS switching equipment required. 

SONDS 
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and the 5 ESS development work. The resulting TNDS "Integration 
Plan" for 5 ESS switching equipment was reviewed by Bell Labora- 
tories and AT&T management, and then was distributed to all orga- 
nizations having responsibility for the TNDS component systems. 
The TNDS integration plan was completed two years before the 
scheduled first 5 ESS service. 

At this point the features needed to support 5 ESS switching 
equipment were added to the feature priority lists for each of the 
TNDS component systems. These 5 ESS features thus became part 
of the overall continuing development process for TNDS. Because of 
the expected widespread deployment of 5 ESS switching equipment 
in the operating companies and the large economic penalties that 
would occur without TNDS support for 5 ESS, the 5 ESS packages 
generally received the highest priority for development. Approval for 
development and for requirements formulation was obtained for each 
of the component systems in time to meet the initial 5 ESS service 
date. Work then started on requirements and design under the normal 
TNDS release process. 

Three interface definitions (5 ESS switching equipment and EA- 
DAS, EADAS and TNDS/EQ, TNDS/EQ and SPCS COER) were 
formulated. These were required because of the decisions to utilize an 
X.25 protocol between EADAS and 5 ESS switching equipment, and 
the need to specify new schedules for extreme value data being selected 
by EADAS. Other requirements for new EADAS, SPCS COER, and 
TNDS/EQ reporting and processing were written. Actual design and 
coding of the various TNDS features began one to two years before 
the scheduled first 5 ESS service. 

A committee of development representatives was formed to coordi- 
nate development activities for first service. Experts from 5 ESS 
switching equipment, EADAS, and TNDS/EQ served on it. This group 
worked out problems in design details and coordinated laboratory-to- 
laboratory testing activity, which generally proceeded in stages from 
basic hardware communications to application process communica- 
tions. In addition, load simulators were used in the development 
organizations to do further interface testing and debugging. A large 
number of measurement definition changes occurred during the 5 ESS 
development. These changes had to be accommodated in the TNDS 
during development. 

The first 5 ESS is owned by the Illinois Bell Telephone Company. 
To test the TNDS features designed to support the 5 ESS switching 
equipment, it was necessary to arrange soak testing of EADAS, TNDS/ 
EQ, and SPCS COER releases in Illinois Bell. Planning for this soak 
testing began about one year before the scheduled first office service. 

Final end-to-end laboratory tests were conducted three months 
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before first service. Initial soak testing with the first 5 ESS began 
about six weeks prior to service. A simulated call load on the 5 ESS 
switching equipment was used for these tests. When the 5 ESS 
switching equipment started handling live traffic, TNDS was in place 
to measure the traffic. Coordinated testing of TNDS components 
under live traffic conditions continued for several months after first 
service. Then the new release packages were made available to other 
TNDS users. 

TNDS was ready to serve the first 5 ESS switching equipment 
because the need for TNDS support and planning was recognized by 
the 5 ESS developers early in their development cycle. Planning, 
requirements formulations, design, code, test, and soak proceeded in 
an orderly manner with careful coordination at each step. Problems 
in scheduling, interface details, and detailed measurement definitions 
were all solved through close coordination of the development efforts. 

4.5 Future directions 

TNDS will continue to evolve gradually. Setting the direction of 
this continuing evolution is the purpose of TNDS long-range planning. 
Long-range planning for the TNDS is a continuous process whose 
output is a series of TNDS feature packages designed to avoid obso- 
lescence and to take advantage of new technology. The results of 
recent long-range planning studies have indicated that further major 
improvements are desirable and appear to offer significant economic 
benefits. Several improvements relating to additional support for 
network administration functions are being studied. These studies are 
aimed at reducing the volume of paper reports produced by the TNDS, 
and providing users more direct control of TNDS operations, and 
flexible user-defined output reports. These objectives are planned to 
be achieved through on-line updating capabilities, expanded user pro- 
grammability features, and provision of a simple standardized human 
interface to TNDS component systems. The next steps are to expand 
the scope of the planning work to include support for other telephone 
company organizations and to define the specific features that will be 
implemented. Through this process of continuous renewal guided by 
a periodically revised long-range plan, it is expected that TNDS will 
continue to serve the traffic-data handling needs of operating compa- 
nies into the next decade and beyond. 
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